refactor: remove emit_interrupt_event from chat protocol [JAR-8666]#104
refactor: remove emit_interrupt_event from chat protocol [JAR-8666]#104JoshParkSJ wants to merge 2 commits intomainfrom
Conversation
JoshParkSJ
force-pushed
the
josh/cas-tool-confirm
branch
from
dd2c4a4 to
fca94f2
Compare
JoshParkSJ
force-pushed
the
josh/cas-tool-confirm
branch
from
fca94f2 to
87f95b2
Compare
| """ | ||
| ... | ||
|
|
||
| async def emit_interrupt_event( |
There was a problem hiding this comment.
Don't remove this, we'll need it in the future. There are multiple types of interrupt, not just tool call confirmation. The runtime contract is fine even if you decide to handle tool call confirmations in another way
There was a problem hiding this comment.
We decided to remove interrupts from conversational agents and only support tool confirmation because interrupts are too much a low-level abstraction and has no use case for convo agents other than tool confirmation
Here is the relevant thread but this is the general consensus amongst other conversational agent SDK as well
| resume_map: dict[str, Any] = {} | ||
|
|
||
| for trigger in api_triggers: | ||
| await self.chat_bridge.emit_interrupt_event(trigger) |
There was a problem hiding this comment.
This line reacts to the interruption in the runtime code (be it tool call confirmation or another type of interrupt)
There was a problem hiding this comment.
We don't have another interrupt type. We assumed there would be other interrupt use case with convo agents but there isn't
There was a problem hiding this comment.
What I'm saying is that you don't need to make any changes to the runtime contracts right now. You can simply leave this code as it is (change the CAS bridge implementation of emit_interrupt_event to no-op).
I want us to be flexible, in case we change our mind again, or decide that we actually need an interrupt event (for coded agents there's nothing preventing the user from doing interrupt("Do you want to continue?") in the coded agent's code. This is something that we'll probably have to handle gracefully at some point
| await self.chat_bridge.emit_interrupt_event(trigger) | ||
|
|
||
| resume_data = ( | ||
| await self.chat_bridge.wait_for_resume() |
There was a problem hiding this comment.
This line waits for the runtime interruption. You can't wait_for_resume without having emit_interrupt_event before. The contract wouldn't make sense
There was a problem hiding this comment.
I've renamed it for clarity. The new pairing is wait_for_tool_confirmation and startToolCall + requireConfirmation: true
|
Will leave interrupt/resume for future flexibility |
2 participants
Summary
emit_interrupt_eventfromUiPathChatProtocoland its call in the runtime loopstartToolCallwithrequireConfirmation: true— the runtime no longer needs to emit a separatestartInterrupteventCompanion PRs: